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Preface 



world 



X/Op^n 

X/Open is an independent, woridwide, open systems organisation supported by most of the 

suppliers, user organisations and software companies. Its 
er value from computing, through the practical implementation 



sj^ Items 



great© 



I s largest information 
mission is to bring to users 
of opei systems. 

X/Open's strategy for achieving this goal is to combine existing and emerging standards into a 
comprjhensive, integrated, h gh-value and usable open system environment, called the 
Common Applications Envirorment (CAE). This environment covers the standards, above the 
hardwire level, that are needed to support open systems. It provides for portability and 
interopierability of applications, and so protects investment in existing software while enabling 
additions and enhancements. I: also allows users to move between systems with a minimum of 
retraining. 

X/Open defines this CAE in a set of specifications which include an evolving portfolio of 

application programming interfaces (APIs) which significantly enhance portability of 
application programs at the source code level, along with definitions of and references to 
protocols and protocol profiles which significantly enhance the interoperability of applications 
and systems. 



The X/Open CAE is implemented 
the X/Open brand — that is 
demonstrated their conformance, 



in real products and recognised by a distinctive trade mark — 
lijcensed by X/Open and may be used on products which have 



X/Operi Technical Publications 

X/Open publishes a wide rang(! of technical literature, the main part of which is focussed on 
specification development, but which also includes Guides, Snapshots, Technical Studies, 
Brandirig/Testing documents, industry surveys, and business titles. 

There are two types of X/Open specification: 

' Specifications 



CAE 



CAE (Common Applications 
form the basis for X/Open 
widely within the industry 



for 



Environment) specifications are the stable specifications that 
tjranded products. These specifications are intended to be used 
product development and procurement purposes. 



Anyone developing product; 
benefits of a single, widely 
comjDliance with the majority 
refei^enced in an X/Open o 
branding programme 

CAE 
with 
way, 



that implement an X/Open CAE specification can enjoy the 
supported standard. In addition, they can demonstrate 

of X/Open CAE specifications once these specifications are 
;6mponent or profile definition and included in the X/Open 



practicable, so enhancing the 



specifications are publi; hed as soon as they are developed, not published to coincide 
the launch of a particuhir X/Open brand. By making its specifications available in this 
X/Open makes it possible for conformant products to be developed as soon as is 
^alue of the X/Open brand as a procurement aid to users. 
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Preface 



often address an emerging area of technology and consequently 
multiple sources of stable conformant implementations, are 
for the purpose of validation through implementation of 
6ecification is not a draft specification. In fact, it is as stable as 
on publication has gone through the same rigorous X/Open 
es as a CAE specification. 



• Preliminary SpeciScations 

These specifications, which 
are not yet supported by 
rehased in a controlled m^inner 
products. A Preliminary s 
X/Open can make it, and 
development and review prpcedun 

Preliminary specifications a e analogous to the trial-use standards issued by formal standards 

organisations, and product development teams are encouraged to develop products on the 
basis of them. However, because of the nature of the technology that a Preliminary 
specification is addressing, ;t may be untried in multiple independent implementations, and 
may therefore change before being published as a CAE specification. There is always the 
intent to progress to a corresponding CAE specification, but the ability to do so depends on 
consensus among X/Open members. In all cases, any resulting CAE specification is made as 
upwards-compatible as possible. However, complete upwards-compatibility from the 
Preiiminary to the CAE specification csmnot be guaranteed. 

In addition, X/Open publishes: 

• Guides 



These provide information 

deVjelopment or managemsnt 
compliant. X/Open Guides 
purposes of specifying or 



Ikchnical Studies 



hat X/Open believes is useful in the evaluation, procurement, 

of open systems, particularly those that cire X/ Open- 
are advisory, not normative, and should not be referenced for 
claiming X/Open conformance. 



X/0pen Technical Studies pjresent 
interest in areas relevant 
con: municate the findings to 
and actions by other bodies ajnd 



results of analyses performed by X/Open on subjects of 
to X/ Open's Technical Programme. They are intended to 
the outside world and, where appropriate, stimulate discussion 
the industry in general. 



Snapshots 

These provide a mechanism for X/Open to disseminate information on its current direction 
and thinking, in advance of possible development of a Specification, Guide or Technical 
Stuc y. The intention is to stimulate industry debate and protot5^ing, and solicit feedback. A 
Snapshot represents the interim results of an X/Open technical activity. Although at the time 
of its publication, there may be an intention to progress the activity towards publication of a 
Specification, Guide or Technical Study, X/Open is a consensus organisation, and makes no 
commitment regarding future development and further publication. Similarly, a Snapshot 
does not represent any commitment by X/Open members to develop any specific products. 



Versions and Issues of Specificadons 

As with all live documents, C/lE 
technology develops and to alijpn 
makes a distinction between revised 

those wnich are not: 



a new Version indicates that 
information from the 
addi ional information. As 



Specifications require revision, in this case as the subject 
with emerging associated international standards. X/Open 
specifications which are fully backward compatible and 



this publication includes all the same (unchanged) definitive 
previcus publication of that title, but also includes extensions or 
such, it replaces the previous publication. 
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changes to the definitive information contained in the previous 
may also include extensions or additional information). As such, 
previous and new issue as current publications. 



• a new Issue does include 

publication of that title (anep 
X/ Open maintains both the 

Corrigenda 

Most jx/Open publications deal with technology at the leading edge of open systems 
development. Feedback from implementation experience gained fi'om using these publications 
occasionally uncovers errors or inconsistencies. Significant errors or recommended solutions to 
reported problems are commui licated by means of Corrigenda. 

The re ader of this document i s advised to check periodically if any Corrigenda apply to this 
public ition. This may be done in any one of the following v/ays: 

• an« inymous ftp to ftp.xopen .org 

• ftpmail (see below) 



To req 



• ref :rence to the Corrigenda 



list in the latest X/Open Publications Price List. 



followmg four lines in the body 



open 



iest Corrigenda information using ftpmail, send a message to ftpmail@xopen.org with the 



of the message: 



cd 

ge 



This V, 



i 
quit 

L 



pub/Corrigenda 
index 



ill return the index of 



Dublications for which Corrigenda exist. Use the same email 
full corrigendum information following the email instructions. 



addres 5 to request a copy of the 
This D ocument 

This document is a Guide (se^ above). It provides a functional description of the X/Open 
Distribjted Transaction Processing (DTP) model, a software architecture that allows multiple 
applica tion programs to share resources provided by multiple resource managers, and allows 
their w ark to be coordinated infc ) global transactions. 



This gjide describes the use 



of the X/Open DTP Model within the X/Open Common 



Applications Environment (CAE), and is a prerequisite to other present and emerging X/Open 



docum ents that address DTP. This guide gives an introduction to the interfaces those other 
documents specify; it defines ter ms that those documents use; and it gives a concise overview of 
the interrelation of those DTP in ;erfaces and of the software components that use them. 



X/ Open DTP publications basec 
portable application programmiii 



on this model specify a portable high-level TP language (HTL), 
ig interfaces (APIs) and system-level interfaces that facilitate: 



• portiability of application pre gram source code to any X/Open environment that offers that 
HTll and/or those APIs 

• intelchangeability of transact on managers and resource managers from various sources 

• inteioperability of diverse tri ynsaction managers and resource managers in the same global 

transactions. 

This guide is structured as follows: 

• Chapter 1 is an introduction. 

• Cha] )ter 2 provides fundamer ital definitions for the remainder of the guide. 
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Preface 



A 



CI- apter 3 describes the X/( )pen DTP Model. 



JfP' 



endix A addresses se me 



frequently asked questions about how existing product 
structures fit within the X/(t)pen DTP Model. 



Inten< led Audience 

This guide is intended to introduce the X/Open DTP Model to application developers, system 
admir istrators and product bt ilders and suppliers. It assumes prior knowledge of distributed 
transa ;tion processing. 

Typographical Conventions 

The following typographical cohventions are used throughout this document: 

• Bo d font is used in texj; for keywords and references to published standards and 
spe cifications. 

• Italic strings are used for emphasis and to identify the first instance of a word requiring 
definition. Italics in text also denote C-language functions; these are shown as follovsre: 
naiieO. 

Superseded Documents 



rsion 3 guide supersed 3S the X/Open Distributed Transaction Processing: Reference 
Version 2 Published in 



This V 

Model Version 2 Published in 1993. Since that version, the X/Open CPI-C, Version 2 interface 

has su jerseded the X/Open Peer-to-Peer interface as one of the three interfaces between an 
Application Program (AP) and i Communication Resource Manager (CRM) . Also, the X/Open 
High-level Transaction Languiige (HTL) has been introduced as an additional means of 
produqing an AP. 



As future developments may 
should consult a current X/Opi 
orderir g copies of individual sp ;clfications, 



;hange the number or titles of relevant publications, readers 
en publications catalogue (http;//www.xopen.org) before 
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( 'hapter 1 



Introduction 



1.1 Oveiview 



The X/Open Distributed Tran 



allows 



manaj ers, and allows their woi k to be coordinated into global transactions. 



TheX 



an 



These 



multiple application 



iaction Processing (DTP) model is a software architecture that 
programs to share resources provided by multiple resource 



Open DTP Model comprises five basic functional components: 

Application Program (AP), which defines transaction boundaries and specifies actions 
that constitute a transaction 

Re5 ource Managers (RMs) sjuch as databases or file access systems, which provide access to 
res )urces 

a Iransaction Manager (TM), which assigns identifiers to transactions, monitors their 



progress, and takes respon 
reo jvery. 

• Communication Resource 



jibility for transaction completion and for coordinating failure 



disi ributed applications and 



Managers (CRMs), which control communication between 



dis ributed applications witMn or across TM domains. 

a c( immunication protocol, which provides the underlying communication services used by 



supported by CRMs. 



lerms are defined more pj ecisely in Section 3.2 on page 8. 



X/Ope a DTP publications basec i on this model specify a portable high-level TP language (HTL) , 
portabi e APIs and sj^tem-level : nterfaces that facilitate: 

• portability of application program source code to any X/Open environment that offers that 

HTL and/or those APIs 

• interchangeability of TMs, R]vls and CRMs from various sources 

• inte roperability of diverse TMs, RMs and CRMs in the same global transaction. 



1.2 Benefits of X/Open DTP 



DistribJited transaction processing provides the necessary mechanism to combine multiple 
software components into a cooperating unit that can maintain shared data, potentially 
spannirfg multiple physical processors or locations, or both. This enables construction of 
IS that manipulate data consistently using multiple products, that can easily 
incorpo rate additional componepts, and that can be scaled by adding additional hardware and 
software components. 



Portability, interchangeability and 
selection of transaction manage :s 
Application writers also gain the 
software platforms. 

Published language and interfac e 
softwar; products that might opce 



interoperability let application writers benefit from a wider 
resource managers and communication resource managers, 
freedom to select from alternative products, hardware and 



specifications simplify software design. For example, some 
have been implemented using customised interfaces may 
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Benefits ofX/^ Dpen DTP 



now 
and 



hi 



All 
open 



part: 



TheX 



viewed as interchange! 
the above benefits 



extends 



Introduction 



ble DTP components. This approach shortens development time 
to a greater number of products. 



X/Op 



ies benefit from the 
systems providers, with 
vendofs (iSVs) and users. 



1 .3 Area s Not Addressed 



specifii !d 
heteroge 
to use 



Data 



/pen method of achieving consensus and communication among 
a significant voice for system vendors, independent software 



Open DTP Model does i lot address all issues of importance in transaction processing, for 



examf le: 

• coi figuration, administratioln and monitoring of transaction processing systems 

• for Tis management and othor user interfaces 

• sptcification of benchmarks 

• secjulty 

• nariing 

• cor imunication techniques that may be used within RM implementations. 
1 .4 Relat ionship to Internal ional Standards 



05I 



The X/|Open DTP Model shows 
in the referenced 
;eneous environments 
product-internal communication 



slructures from the refere iced 
transaqtion identifier that X/Opin specifii 



that DTP software components use the communication protocol 
TP standards to facilitate interoperability of components in 
use of OSI TP is not mandatory where implementors require 
provider. 



the 



OSI CCR standards are a recommended component of the 
es. 
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(ihapterZ 

Definitions 



This chapter gives fundameiftal definitions on which subsequent chapters depend. It Is 
structured as follows: 

Trzlnsactlon Definitions 

Mddel Definitions. 



(AP) , Resource Manager (RM) , Transaction Manager (TM) and 
iger (CRM) are defined in Section 3.2 on page 8. 



The terms Application Prograrn 
Comrrlunication Resource Man i; 



Tran taction Definitions 



Transi ction 

A tran, iaction is a complete unit of work which, in general terms, can apply to many contexts. It 
may comprise many computational tasks including user interfaces, data retrieval and 
communications. A typical transaction modifies resources. The model described in the 
referer ced OSI TP standards defines the term transaction more precisely. 

This guide refers to specific typos of transaction, such as global and distributed. These are defined 
below. 

Transs ction Properties 

Transa :tions typically exhibit thje following properties: 

The results oJf the transaction's execution are either all committed or all rolled 
back. 



Atomi ;ity 
Consistency 
Isolatii m 
Durab: lity 



A completed 
another valid 



The changes 



system or media failures 



Global 



The te-m global transaction co 
anjwb;re in the network for a 
transacpon. A single, coordinating, 



transaction transforms a shared resource from one valid state to 
state. 



Changes to shared resources that a transaction effects do not become visible 
outside the transaction until the transaction commits. 



that result from transaction commitment survive subsequent 



These properties are known by their initials as the ACID properties. In the X/Open DTP Model, 
the T]y coordinates Atomicity at global level whilst each RM is responsible for the Atomicity, 
Consisi ency, Isolation and Durability of its resources. 



Transaction 



lectively describes all the work done by participating RMs 
jingle unit of work. An AP defines the start and end of a global 
, TM manages its initiation and completion. 
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Transaction Definitions 



Definitions 



Distri 3uted Transaction 



This guide uses the term globa\, rather than distributed, transaction. Chapter 3 concentrates on 
global transaction processini 

and it! ; distribution across physjical locations, network nodes or TM Domains. 



Transaction Completion 
Transaction completion means 

Comnlitment Protocol 



DTP ]»lodel follows the two 



Comnjiitment 

Commitment is the act that ends a transaction and makes permanent all changes to resources 
specif ed during that transactio ri. 

Rollback 

Rollbakk is the act that ends a transaction and nullifies or undoes all changes to resources 
specifi ed during that transactio i. 



either commitment or rollback. 



A comi nitment protocol is the syrchronisation that occurs at transaction completion. The X/Open 



ohase commit with presumed rollback^ protocol defined in the 



referenced OSI TP standards. A. description of the basic protocol is given in Section 3.4.3 on page 
13. In certain cases, a global transaction may be completed hewistically . Heuristic transaction 
compl ition is described in Secti m 3.4.5 on page 14. 



RM Resource 



In the 



an 



resour ;e 



X/Open DTP Model 
;e may be shared with other 



RM Ni itive Interface 



RJl 



The 

The 
portab 



I's native interface is the 

may support a standaijd 
lie to other RMs that usf 
propri* itary interface specific to 



1. To aid readabiliti', 
rollback. 



RM resource is the collection of data that an RM manages. A 
global transactions or dedicated to a single transaction. 



RM-defined API by which an AP operates on the RM's resource, 
interface, such as SQL or ISAM, in which case the AP may be 
the same interface. The RM may, on the other hand, offer a 
its services. 



some parts of this guide use 



the term two-p/iase commit as an abbreviation of two-phase commit with presumed 
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2.2 Model Definitions 



Instance of the Model 

An imtance of the model (or iistance)^ is the set of computing entities that Implement the 
functional components and inlerfaces of all or part of an application within the X/Open DTP 
Model. Each instance may support one AP, one TM and multiple RMs. A distributed application 
is repi Bsented by two or more i nstances and includes a CRM in each instance. An instance is part 
of a sii igle TM Domain. A TM I Domain can contain one or more instances. 

The possible implementation c f product structures that make up an instance may vary from 
simple to very complex. Appendix A addresses some frequently asked questions about how 
existirte product structures fit within the X/Open DTP Model. 

TM D( imain 

A TM Domain consists of one or more instances that use the same TM. This TM is common to all 
applications that run within t iat TM Domain. The common TM uses logically-shared data 
structvres and logs for global-transaction management, such as when issuing global transaction 
identif ers or when coordinating; global-transaction recovery. 

The figure below illustrates foui instances of applications within a single TM Domain. The TM is 
the sar le in each instance and is labelled TMl. Different RMs may participate in each instance. 



RMs 



RMs 



AP 



AP 



TMl 



RMs TMl 



AP 



AP 



^TMl 



RMs TMl 



Figure 2-1 A TM Domain with Four Instances 



2. To aid readability some parts of this guide use tb e term instance as an abbreviation of instance of the model 
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Model Definitions 



X/Op(n DTP Model 

At a b isic level, the model is a 
provic ed by multiple RMs 
coordinated into a global trans: 



The fi] 11 model is a software 
by multiple RMs located acros^ 
coordinated into a global trajisaction 
languc ge, the TX, XA and 
Resource Manager (CRM) spec^ficat: 
XAP-1 P interface to coordinate 

Threa Is 



Definitions 



software architecture that allows a single AP to share resources 
wjthin a single TM Domain, and allows RM-internal work to be 
ction using a single TM. It uses the TX and XA interfaces. 



architecture that allows multiple APs to share resources provided 
one or more TM Domains, and allows RM-internal work to be 
using multiple TMs. The full model uses the STDL 
interfaces, the interfaces provided by the Communication 
ions, namely TxRPC, XATMI and CPI-C, Version 2, and the 
communication through OSI TP. 



A thread is the entity, with all its context, that is currently in control of a processor. For 
portability reasons, the notion cf thread must be common among the AP, TM and RM. 

The thread concept is central to the TM's coordination of RMs. APs call RMs to request work, 
while TMs call RMs to delineate transaction branches. The way the RM knows that a given 
work lequest pertains to a given branch is that the AP and the TM both call it from the same 
thread. For example, an AP thr ;ad calls the TM to declare the start of a global transaction. The 
TM records this fact and informs RMs. After the AP regains control, it uses the native interface 
of one or more RMs to do woijk. The RM receives the calls from the AP and TM in the same 
thread 
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Chapters 

The Model 



This c lapter gives an abstract 
enviro nment for global transacfion 



(description of the X/Open DTP Model of an application program 
processing. 



3.1 Functional Model 

The bAxes in the figure below 
interfaces between them. The 



, are the functional components and the connecting lines are the 
arrows indicate the directions in which control may flow. 



SUPERIOR NODE 



Application Progran: (AP) 



AP Written Using 
STDL 



(1) 




(2) 



Transaction 
Manager 
(TM) 



OSITP 



AP Written Using 
Other Languages 



(4) 



(5) 



Communication 
Resource 
Managers 
(CRMs) 



(6) 



Figure 3 



1 Functional Components and Interfaces 



Descrij tions of the functional 
numbers in brackets in the aboA 
in the r lodel. They are describe i 
descrip tion of how the model wprks 



c omponents shown can be found in Section 3.2 on page 8. The 
e figure represent the diiferent X/Open interfaces that are used 
in Section 3.3.1 on page 10. The subsequent sections provide a 



SUBORDINATE NODE 



RMs 



TM 



OSITP 
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3.2 
3.2.1 



3.2.3 



Fum tional Component s 

Appl: cation Program (AP) 

The application program (AP) implements the desired function of the end-user enterprise. Each 
AP sp Jcifies a sequence of opei ations that involves resources such as databases. An AP defines 

the stc rt and end of global transactions, accesses resources within transaction boundaries, and 
normc lly makes the decision whether to commit or roll back each transaction. 



Where 
three 
2 



two or more APs co' 
haradigms for AP-to-AP 

, described in Sectioh 



inter Faces 



Where 
the 

be 



operjate within a global transaction, the X/ Open DTP Model supports 
communication. These are the TxRPC, XATMI and CPI-C, Version 

3.7 on page 21. 



other 



ippoit 



two or more APs su 
AP(s) the subordinate^ 
prcjvided by subordinates; 
superior AP can have many 
superi )r. A subordinate AP caii 
hieran hy of APs can be built uf 



a global transaction, one AP is designated the superior AP and 
s). The superior AP makes distributed requests for services to 
for example, service requests using the XATMI interface. A 
siibordinate APs whereas each subordinate AP has only a single 
also be superior to other APs working at a lower level. Hence a 



An AF acting as the superior 
example, depending on the conhmunication 
start and commit a global transaction 
transaction. 



ypically exerts more control than any of its subordinates. For 
paradigm, only the superior AP may be allowed to 
Its subordinates however may roll back the global 



APs can be written using the X/'Open HTL, the X/Open APIs or a combination of the two. See 
Section 3.8 on page 23 for further information on the X/Open HTL. 



3.2.2 Transaction Manager (TM) 

The tra nsaction manager (TM) 
them, e nd commit them or roll . 

also CO ardinates recovery activi 
compo lent fails. 



r lanages global transactions and coordinates the decision to start 
them back. This ensures atomic transaction completion. TheTM 
ties of the resource managers when necessary, such as after a 



In addi :ion, the following information applies where two or more TMs cooperate within a global 
transac ion. 



The TK [ that works on behalf ofi the 

design? ted subordinate TMs. T' 
their respective APs. Within a 
own instance of the model, 
commu nicate global transaction 



superior AP is designated the superior TM. Other TMs are 

le superior/subordinate relationship is the same for TMs as for 
,lobal transaction, each TM only controls those RMs within its 
Through their CRMs (see Section 3.2.4 on page 9), TMs 
information between each other by use of the XA+ interface. 



Resoui ce Manager (RM) 

The res jurce manager (RM) manages a defined part of the computer's shared resources. These 
may hv accessed using services that the RM provides. Examples for RMs are database 
management systems (DBMSs) , a file access method such as X/Open ISAM, and a print server. 

In the X/Open DTP Model, FMs structure all changes to the resources they manage as 
recover ible and atomic transactions. They let the TM coordinate completion of these 
transactions atomically with woik done by other RMs. 

In addi ion, the following infoimation applies when RMs take part in a global transaction 
involvir g two or more TM Domj ins or instance of the model. 
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Withii I the context of the 
only f] om the TM in the 
provic ed through the XA 
comm inicate with its TM. 



view (pf 
detaile d 
RM-in 
divers ; 



CRM 



A 

curren : 



follow. 
. the 



CRvI 



X/Open DTP Model, an RM receives global transaction information 

instances of the model with which it is registered. This information is 
interface. An RM uses the ax_*() functions of the XA interface to 



Outside the X/Open DTP Model context, an RM is free to access data at many physical 
locatic ns. For example, a Relat onal Database Management System (RDBMS) may use a gateway 
technc logy to access a remote d atabase. The RDBMS presents the AP with a single-image logical 
the database concerne i, and the AP is not aware of either its physical location or the 
structure of its components. In such a setup, the RM must be able to complete its own 



ernal work atomically, 
are its resources. 



on behalf of the global transaction, no matter how physically 



3.2.4 Comitiunication Resource N [imager (CRM) 

the model to access another instance either inside or outside the 

the X/Open DTP Model, CRMs use OSI TP services to provide a 
TM Domains. CRMs aid global transactions by supporting the 



allows an instance of 

TM Domain. Within 
commilinication layer across 
ng interfaces: 



• XA f communication between a TM and CRM 
XAP-TP communication betjveen a CRM and OSI TP. 



ACRN[ 
difFerei it 



one type of communication paradigm, or a TM Domain may use 
CRMs to support diffdrent paradigms. The XA+ interface provides global transaction 
information across different instances and TM Domains. The CRM allows a global transaction to 

and allows TMs to coordinate global transaction commit and 
rjequests from (usually) the superior AP. Using the above interfaces, information flows 
to subordinate an d vice versa. 



extend 
abort 
from 



The 
other 
s 

This 
that a 

requesl 
shown 



SI ipenor i 



CFM 



that supports the supprior TM is called the superior CRM. Other CRMs, that support 
TMs, within the g obal transaction, are called subordinate CRMs. The 
uperic r/subordinate relationship is the same for CRMs as for their respective APs and TMs. 
m ;ans that a CRM can only directly support the AP and TM of its own instance. It follows 
( ;RM in one instance canr ot directly support an AP and TM in another instance, but must 
the services of the CRT /I for that instance. This paired relationship between CRMs is 



in Figure 3-1 on page 7. 



may support more than 



communication paradigm CTxRPC, XATMI or CPI-C, Version 2) used between an AP and 
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Interfaces betwreen Functional Components 



3.3 
3.3.1 



Intel faces between Functional Components 

Funct ional Component Inte faces 

There ire six interfaces between software components in the X/Open DTP Model. The numbers 
corres lond to the numbers in Figure 3-1 on page 7. 

interl aces give the AP access to resources. X/Open interfaces, such as 
AP portability. The X/Open DTP Model imposes few constraints 
;onstraints involve only those native RM interfaces that define 
referenced XA Specification.) 



(1) AP-RM. TheAP-RM 

S(^L and ISAM, provide 
on native RM APIs. The 
transactions. (Seethe 



(2) AP-TM. The AP-TM 

w ith the TM. For example 
R As of the start of a globa 
re turn value to the AP 



F( r details of the AP-TM 
(Transaction Demarcation) 



Inj addition, the following 
gl 3bal transaction. 

If the AP is designated 
tri msactions. If the AP 
communication paradigm 

A i'-TM interface. For exa: 
transaction commitment. 



gl 



m 



3. The TX (transact on 
case for C — foi 
guide uses the C 

4. The XA interface 



The Model 



interface allows the AP to coordinate global transaction management 
when the AP calls tx_begm(), the TM informs the participating 
transaction. After each request is completed, the TM provides a 
repdrting back the success or otherwise of the TX call. 



interface, see the referenced STDL Specification and the TX 

Specification.^ 

information applies when two or more APs cooperate within a 



as 



the superior, it uses the AP-TM interface to delimit global 
is designated as a subordinate, then depending on the 
employed, it may not be permitted to use all the facilities of the 
mple, the subordinate AP may not be allowed to request global 



TM may receive global tjransaction information from another TM routed through remote 
ar d local CRMs. For exar iple, a superior TM may inform subordinate TMs to commit a 

the subordinate APs' knowledge. Subordinate APs can, 
informatjion about the current global transaction context by calling 



jbal transaction without 
he wever, access 
tx_mfo{). 



(3) TM-RM. TheTM-RM 

o global transactions 



interface 



and 



Ti e functions that each 
example, the TM calls 
tn nsaction as part of a new 
xa_prepare{) and xa_comm 
prstocol. The functions 
For example, an RM calls 



Tl e TX and XA interfaces 
AI ' and TM and, at a lower 



(the XA interface) lets the TM structure the work of RMs 
coordinate completion or recovery. The XA interface is the 
bitiirectional interface betWeen the TM and RM. 



FM 



provides for the TM are called the xa_*{) functions.* For 
start 0 in each participating RM to start an RM-internal 
global transaction. Later, the TM may call in sequence xa_end{), 
to coordinate a (successful in this case) two-phase commit 
the TM provides for each RM are called the ax_*() functions. 
regO to register dynamically with the TM. 



thk 



For details of the TM-RM ir terface, see the referenced XA Specification. 



c joperate to provide global transaction management between the 
level, the TM and participating RMs. The TX interface drives the 



4des both a C and a COBOL programming interface. TX functions are in lower- 
i]n upper-case for COBOL — for example, TXCOMMIT. To aid readability, this 



demarcation) interface pro' 
example, tx_conmdt() — and 
versions only. 

is a C interface only, between the TM and RM. It is not accessed directly by the AP. 
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X \^ interface when managi|ng 
tlie success (or otherwise) 
returned information 
tr msaction management at 



Since the XA interface is 
interconnect without 



g 



Interfaces between Functional Components 



global transactions. The XA interface reports back to the TM 

Df global transaction work at RM level. The TM then collates the 
ind reports back to the AP the success (or otherwise) of global 
TM level. 



invisible to the AP, the TM and RM may use other methods to 

affectjing application portability. 



(4) Tkl-CRM. The TM-CR]\)1 
in formation flow across 
function calls to suspenc 
tr insaction commitment 
TMs in subordinate 
calls to request the TM 
recovery information, and 

Fc r details of the TM-CRM 



to 



interface (the XA+ interface) supports global transaction 
Domains. In particular TMs can instruct CRMs by use of xa_*{) 
or complete transaction branches, and to propagate global 
pj-otocols to other transaction branches. CRMs pass information to 
branches by use of ax_*() function calls. CRMs also use ax_*() function 
create subordinate transaction branches, to save and retrieve 
;o inform the TM of the start and end of blocking conditions. 

interface, see the referenced XA+ Specification. 



The XA+ interface is a superset of the XA interface and supersedes its purpose. Since the 
interface is invisible to the AP, the TM and CRM may use other methods to 
in:erconnect without affect ng application portability. 

(5) A '-CRM. X/Open provides portable APIs for DTP communication between APs within a 



Ijbal transaction. The 

fundamental to) the whole 



^I chosen can significantly influence (and may indeed be 
architecture of the application. For this reason, these APIs are 
frequently referred to in this guide and elsewhere as communication paradigms. In practice, 
ea :h paradigm has unique ; strengths, so X/ Open offers the following popular paradigms: 

the TxRPC interface (set; the TxRPC Specification) 

the XATMI interface (se» the XATMI Specification) 

the CPI-C, Version 2 intcjrface (see the CPI-C, Version 2 Specification). 

Tl ese paradigms are described in more detail in Section 3.7 on page 21. 

X/ 
ac 



Open interfaces, such as 
OSS products offering ihe same CRM API, 
cohstraints on native CRM APIs, 



(6) CljiM-OSI TP. This 

a CRM and Ope 
; TP) services. XAP-TP 
seven-layer OSl mod|el, 
1 plementations of 
CO nmunication between 
rel erenced XAP-TP Specifidat 



be .ween 
(OSI 
tb! 
im 



the three CRM APIs listed above, provide application portability 
The X/Open DTP Model imposes few 



interfkce (the XAP-TP interface) provides a programming interface 
n Systems Interconnection Distributed Transaction Processing 
interfaces with the OSI TP Service and the Presentation Layer of 
X/Open has defined this interface to support portable 
application-specific OSI services. The use of OSI TP is mandatory for 
heterogeneous TM domains. For details of this interface, see the 
ion and the OSI TP standards. 



Distributed Transi ction Processing: Reference Model, Version 3 



11 



Interfaces between Functional Components 



3.3.2 Data nterfaces 



Transaction Identifier 

A trarjsaction identifier (XID) 
relatio iship between an AP, 
manag es on behalf of the AP. 

The X: D lets the TM track and 
Each I'M maps the XID to the 
global uniqueness, the XID sho|uld 
OSI C( 'R standards. Formore 



XA Sv itch Structure 



Each 
as the 



FM 



provides a set of poinjters to the functions that the TM calls, in a data structure known 
t A Switch structure. 



The Model 



is a data structiure that a TM assigns. It represents the unique 
thp work it issues to RMs, and the global transaction which the TM 



coordinate all of the work associated with a global transaction. 
RM-internal work it does for the global transaction. To ensure 
contain atomic action identifiers as specified in the referenced 
itiformation on XIDs, see also the XA Specification. 
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3.4 

3.4.1 



Activ ity between Funct: 



Trans action Initiation 

When an AP instructs its TM 
in ord< sr to associate with the ; 



Some 
Insteacjl 
AP 



' cal Is 



IMs are configured so 
the RM contacts the 
it to request actual 



3.4.2 Trans iction Association 



A thread working on a transaction branch may suspend association with that transaction branch 
when blocking, awaiting a message from another application. The TM may resume the 

or optionally in a different one subject to RM control. The TM 
;usper|ds an association by issuing xa_end{) to the local RMs with the TMSUSPEND flag set. 
also sets the TMMIGR/ J'E flag if it might resume the association in a different thread. If 
permit migration, the TM may resume the association in the same or a different thread. 
Other\j/ise, the association must be resumed in the same thread. Each RM must retain 
transaction context (for example, locks and cursors) while the association is suspended. 



iTH 



3.4.3 Trans; iction Commitment 



When bn AP instructs its TM tb 
two-pl ase commit protocol tc 
initiate commitment, 



In 
its 

global 

report; 

In 

global 
responfees 



Pha! le 



return 



When 
whether 
from 



TheXfi 



An 

was 



The 
specific 



Acti\ity between Functional Components Involving a Single AP 



to 



onal Components Involving a Single AP 



start a global transaction, the TM informs all participating RMs 
;lbbal transaction any work the AP may request of them. 



the TM does not inform them when a global transaction starts, 
to become associated with a global transaction only after the 
woilk. This is known as dynamic registration. 



thkt 
TM 



Phaie 1, the TM issues xa_ 
wor k and report whether it 
transaction. If an RM 
failure for any reason. 



RlAs 



2, the TM directs all 
transaction. Whether th|e 

during Phase 1 . All 
status to the TM. 



I all 



RM can withdraw from 



commit a transaction, the TM and participating RMs use the 
ensure transaction atomicity. The AP requests that the TM 



i_pr&pare() which requests each participating RM to prepare to commit 
c m guarantee its ability to commit the work it did on behalf of the 
can commit its work, it replies affirmatively. A negative reply 



either to commit or roll back the work done on behalf of the 
TM issues xa_commit{) or xa_roUback{) depends on the RMs' 
IlMs commit or roll back changes to shared resources and then 



in AP requests commit: nent of a global transaction, the TM reports back to the AP 
commitment or roUbaJc was the outcome. This is based on reports the TM received 



participating RMs. 

Specification contains t\Vo optimisations in the calling sequence between TM and RM: 



Further participation in a global transaction during Phase 1 if it 



not asked to update resc urces. This is known as read-only optimisation. 



ATM can use one-phase commit if it is dealing with only one RM that is making changes to 
resc urces. 



Specification discusses 
s when the TM and part 
transaction. See the referenced 



requirements for the stable recording of transaction data, and 
icipating RMs are free to discard their knowledge of the global 
XA Specification for further details. 
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On 
tha 
TM. 



The Model 



3.4.4 Trans iction Rollback 

Transa ction rollback can occur ijn three ways: 

• Exjtlicit Rollback 
Th( ! AP requests explicit rolljback of the global transaction. 

• Im )licit Rollback 

Th( TM rolls back the glo|)al transaction if any RM responds negatively to the Phase 1 

request. 

• Pre sumed Rollback 



restart, an RM rolls back any transaction that was active at the time of failure, provided 
it has not already respt >nded positively to a Phase 1 prepare to conanit request from the 



In eac i case, the participating RMs must not allow any changes to resources to become 
permai lent. 

3.4.5 Heuri itlc Transaction Completion 

In cert tin unusual cases, an Rl^'I may unilaterally commit or roll back changes to recoverable 
resourc es that it made within a global transaction. This may happen, for example, when the RM 
experie nces too long a delay bei ween Phases 1 and 2 of the two-phase commit protocol, or it is 
ed by operator intervention to complete (commit or rollback) its RM-internal transaction. 

make a heuristic decision. Such a decision is made by the RM 
of the global transaction of which it is part. The RM may then 



prompi 
In sue! 

without 
unlock 



shared resources and allow other global transactions to make further changes. 



If a hejiristic decision is taken, 
comple t( 



decisioti 
heuristi 

CO 

RMs. 
made 
heuristic 



its own 
request 
comple 



cases, the RM is said tc 

knowledge of the state 



it is possible that at a later point the global transaction may 
e with a decision contrary to that made by the RM. In such a circumstance, the global 
transaction fails to maintain global ACID properties. In other cases a TM may not be able to 
determine whether an RM's heuristic decision matched the TM's global transaction completion 

decision is reported by an RM, the TM reports to the AP that a 
This decision is either contrary to the AP's direction or both 
mple|mentary and contrary (i^ixed) depending on the combined results from all participating 
the TM cannot determine whether an RM's heuristic decision matches the decision 
the TM, the TM reports to the AP that there is a possibility {hazard) of a contrary 



If a contrary heuristic 

c decision has occurred 



If 



decision. 



knowledge of the 
xa_recover() of an RJV 
ed and prepared transacpons. 



In the J^/Open DTP Model, an RM that reports heuristic completion to the TM must not discard 

decis|ion until authorised by the TM. Until this happens, a TM can 
to collect a list of transaction identifiers for heuristically 



The ref( irenced OSI CCR standards define heuristics more precisely. 
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3.4.6 Reco\ ery after Failure 



Recovery is the process of 
Recov( ry processing in an 
standards, which define the 
follow ng assumptions: 



tha: 

tha 

tha 



restoWng resources to a consistent state after various types of failure. 
X/Open DTP system is compatible with that described in the OSI TP 
presumed-rollback protocol. The X/Open DTP Model makes the 



the TM initiates and corltrols 
RMs provide for their 



the TM and RMs have ajccess to stable storage 

transaction recovery 
ayvn restart and recovery as directed by the TM. 



Distributed Transa 



tion Processing: Reference 
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3. 5 Dist ibuted Communic ation Facilities 



o - 



two 
domaih' 



The X 
OSI T& 



Comr lunication within TM 



Distributed applications that 
model may communicate with 

more instances is m. 
s TM used in the 



Communication across TM 



'Open DTP Model s 
protocol as a commoh 



speciiies 



protoc d1 may be used between 



Sharing Resources across T14 Domains 



TM Domains may sha: 
several TMs that ha\ 



TM Ddmains may share resour(j;es in ways other than by using CRMs. For example, RDBMSs in 
different ' 
XIDsl 
and i 
page 
associdt 



f om 
ac herence 
12) 



ted transaction branches 



3.5.4 Globa 1 Trzinsaction Demarcation 



The 
define 
starts i 
RMsb 



II) 



TM interface is used 
global transaction start, 
global transaction, it is 
the AP during this 



TheT> 
mode 



The Model 



Domains 



s ipport global transactions across two or more instances of the 
each other within a single TM Domain. Communication between 
anaged at each end by a CRM. The RMs coordinate with the 
appro ariate instance. 



Domains 



that heterogeneous TM Domains support CRMs that use the 
communication layer. Proprietary protocols or the OSI TP 
■ lomogeneous TM Domains. 



e a common back-end database. In this case, an RM may receive 
e no knowledge of each other. Use of a common format of XID, 
to the rules for Uniqueness of the global transaction identifier (see Section 3.3.2 on 
ensure that the RM can distinguish between different global transactions and their 



the X/Open DTP Model application program environment to 
end, commitment or rollback and other facilities. Before an AP 
in non-global transaction status, and so any work requested of 
peridd is not part of a global transaction started later. 



interface supports the concept of unchained and chained global transactions. In unchained 
which is the default), when a global transaction completes, a new transaction does not 
automatically start until the AP calls tx_beginO again. 

When n chained mode, after tl e initial global transaction starts and completes, the next global 
transaction is started automaticcilly. 

Globa I Transaction Tree Stri icture 



Within the X/Open DTP Mod 
manag ;d by use of a tree structitre. 



il, global transactions that operate across distributed APs are 
This is shown in Figure 3-2 on page 17. 
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1 



/ 

I / 



_ / \ 
■J / 

1^ 



Superior 
\ 

S \ 



3.5.6 Globa 



OSITP 



TM CRMs 



; * TM ^ CRjMs _ I 



Figure 3-2 Global Transaction Tree Structure 



When 
global 

Especially, an instance that does 

Anexa 
is a 



distributed communication occurs between two instances, they have a relationship of 
and Subordinate. The instance that requests the participation of another instance in a 
transaction is called a superior. The requested instance is called a subordinate, 
not have a superior is called a root. 

nple of this is shown in I igure 3-2, where 2b is a superior to both 3b and 3c; 2b, however, 
sut ordinate to 1. 



A globid transaction has one or 



work ir 



During 
subord: 
CRM 



respon; e 



two-phase-commit procfessin: 
nate TMs and their part 
reporting back to the sujDerior 
to prepare and commit 



Transactions and the 



Transaction Tree 



more transaction branches. Each branch represents part of the 
support of a global transaction for which a TM and set of participating RMs engage. 



ig, the superior TM manages commitment coordination with 
cipatlng RMs at branch level. This is achieved by the superior 
TM the success or failure of one or more branches in 
requests. 
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3.5.7 Tight 



Many application threads can 
these iireads is atomically crtm 
between any pair of participatiri: 



A 
In 

Thjis, 
doc IS 



y- and Loosely-couplfd Threads 



participate in a single global transaction. All the work done in 
mpleted. Within a single global transaction, the relationship 
g threads is either tightly-coupled or loosely-coupled: 



ightly-coupled relations!: ip 
^ iddition, with respect to 
for a pair of tightly-^ 
not occur within the 



is one where a pair of threads are designed to share resources, 
an RM's isolation policies, the pair are treated as a single entity, 
pled threads, the RM must guarantee that resource deadlock 
trinsaction branch. 



oosely-coupled 
iso ation policies, the pair 
tho ugh the work is atomical 



Withir a single global transaction 
a pair Moreover, many sets 
transaction and each set is 



3.5.8 Comn litment Coordination 



The TI i that manages global 
the AP of the commitment coor<|linator 



The Model 



relationship provides no such guarantee. With respect to an RM's 
rr ay be treated as if they were in separate global transactions even 

y completed. 



lit, a set of tightly-coupled threads may consist of more than just 
of tightly-coupled threads may exist within the same global 



— ~Q J — — J 

loosely coupled with respect to the others. 



tijansaction completion is called the commitment coordinator. It is 
instance of the model that requests commitment. 
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3.6 Acth 'ity between Funct lonal Components Involving Two or More APs 



In adc ition to the description 
following information applies 
transa ;tion. 



With 
TMto 
first 



Activity between Functional Components Involving Two or More APs 



(Pf 



3.6.1 Trans action Initiation 



When 



to 



an AP makes a request 
suborc inate must be created, 
is calleld TM-managed transactioi > 



managed transaction 
build and log details of i 



til ne. 



With CiRM-managed transactioh 

it with 3Ut involvement from th ; 
effect i i acting as the distributee 



In eitier case, subsequent 
transaction branch. A CRM 
branches. 



The CI 'M uses transaction branches to target global transaction coordination information passed 
on to tjie (subordinate) branch \ ia XA+ commands issued by the TM. 

A CRM can be configured so tliat the TM does not inform it when a global transaction starts. 

Such a CRM contacts the TM to become associated with a global transaction only after the AP 
calls it to make a distributed request. This is known as dynamic registration. 



3.6.2 Transs iction Association 



CIM 



The 
the Tlv: 
resume 
CRM 
mustb 



suspends the association 
with the TMSUSPEND 
the association in a diff(!rent 
i"(iay resume the associati 3n 
resumed in the same thi ead 



3.6.3 Transs ction Commitment 



If the 
transac 
tr ansae 
their 



transaction management given in Section 3.4 on page 13, the 
when two or more distributed APs cooperate within a global 



a remote AP for the first time, a new transaction branch for a 
Tj'here are two methods of creating and managing branches. One 
branches, the other is called CRM-managed transaction branches. 



3ranches, the CRM local to its instance of the model requests the 
new transaction branch prior to accessing the remote AP for the 



branches, the CRM builds the transaction branch and manages 
TM. Such a CRM appears to the TM as an ordinary RM, but in 
manager of the TM in the global transaction. 



accesses 



to the same remote AP are made through the same 
accesses different remote APs through different transaction 



of a thread with a transaction branch by issuing ax_enc/() to 
flag set. The CRM also sets the TMMIGRATE flag if it might 
thread. If the TM and all local RMs permit migration, the 
in the same or a different thread. Otherwise the association 
(See Section 3.4.2 on page 13). 



When in AP in the root or 
follows the two-phase commit 
particij ating RMs, the superioi ■ 
within the global transaction to 
subord nate TMs in other brandhes 
transacpion branch response. 



superior instructs its TM to commit a global transaction, the TM 
j>rotocol. In addition to Phase 1 coordination of commitment of 
TM uses its CRM to instruct all other transaction branches 
prepare to commit. The CRM passes an xa_prepare{} request to 
The CRM then waits for and returns to its own TM each 



TM receives a positive 
ion branches, the TM 
ion. The TM again use;; 



response from its participating RMs and from all associated 
initiates Phase 2 by requesting xa_commit{) of the global 
its CRM to instruct all other transaction branches and await 



re jponse. 



Distributed Transe ction Processing: Reference 



Model, Version 3 



19 



Activity betwt )en Functional Compoi lents Involving Two or More AF^ 



3.6.4 Transktion Rollback 

If the ' M receives a negative 
brand es, the TM initiates Phas;e 
again ilises its CRM to instruct 



3.6.5 Heuri stic Transaction Comp iletion 



When a global transaction 
commynication, RMs in any of 
Phases 1 and 2 of 
might have delayed the 
page 14 describes, a 
a^coiAmitO instruction from 



betwe( ;n 
failure 
3.4.5 

Xi 



on 



Durin; 
trar 
TM 



lo{;s 



I some 



In 

to detdrmine 
logs th 



the 



The Model 



response from a local RM or from any of the associated transaction 
2 by requesting xa_roUback () of the global transaction. The TM 
tl~ansaction branches and await their response. 



extends across two or more transaction branches through 
the branches of subordinates might experience too long a delay 
) two-phase commit protocol. For example, a communication 
commit/rollback indication from the superior TM. As Section 
Subordinate RM may choose to complete its work without the 
TM. 



lase 



Phase 2 of the two-ph; 
transaittion branch that heuristjic 
the response and inforijns 



cases — for example, 

whether heuristic 
fact and informs the 



a'ter 



a communication failure — the superior TM may not be able 
completion of a subordinate RM has occurred. The superior TM 
AP. 



superior i 



3.6.6 Recov ery after Failure 



Recovery processing in an X/Open 
additic n, when a global transaction 
may rjquest ax_recover{) of 
transac tions for which the TM hlas 



commit protocol, the superior TM receives a response from a 
completion of a subordinate RM has occurred. The superior 
the superior AP. 



DTP system is described in Section 3.4.6 on page 15. In 
extends across two or more transaction branches, a CRM 
TM to collect a list of transaction identifiers for prepared 
information logged on behalf of the CRM. 
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TxRPC 



CR]V Communication Paradigms with APs 



The TxRPC Interface 



For di; tributed applications 
Distrituted Computing Services 

interface is offered. 



TMs 



same jbrm as local procedures, 
The environment where 
procedure, and waits 



client. 
remote 



interfa 



the server. 

Calls that have either transaction 
operati ons. If a TxRPC operation 
becom js a transactional RPC. 



e optionally permits the 



CRM Communication Paradigms with APs 



using the remote procedure call (RPC) mechanisms of the X/Open 
pCDCS) Framework, a Transactional Remote Procedure Call, 
allows application writers to invoke remote procedures in the 
Typically the calling environment is an AP referred to as the 
the call is processed is referred to as the server. The client calls a 
the results of the call. When the server finishes processing the 
procec^ure, it returns the resvjlts to the client which then resumes execution. The TxRPC 

AP to extend the scope of a global transaction from the client to 



fcr 



parameters used in the call, plus additional global transaction 
to the client and server APs via an Interface Definition 



Describtions of the types of 
information semandcs, are available 
Languige (IDL). 

For dellails of this interface, see ihe referenced TxRPC Specification. 
The XKTMI Interface 



usini 



For distributed applications 
the X/TMI interface. This interface 
perfori ned. A service is an AP 
the cli( nt. The structure of the 
structure of the service routine 



1 13 

XAHM. supports two types of service: 
Re( uest/Response 

These 



The client AP can make 
;uspended until a response 



The client AP can make 
hen continue work whil^ 
act, make other reques 
simultaneously processed 
: eturns a ca7i descriptor 
pgetrplyi) to receive a 

Coiiversational Services 



mandatory or transaction-optional attributes are called TxRPC 
takes place within the scope of a global transaction, the call 



g service requests in a client-server paradigm, X/Open offers 
supports the use of client APs requesting services to be 
rjDutine that performs a specific application function on behalf of 
client AP is defined entirely by the application writer and the 
defined by the XATMI interface. 



services receive a single request from a client AP and produce at most a single 
resi|)onse to the request. Requests can be made in two ways: 

synchronous request by calling tpcaU(). The client AP is then 
is received. 



n asynchronous request by calling tpacallQ. The client AP can 
the service routine processes the request. The client AP may, in 
3 and so exploit parallelism since multiple requests can be 
by different service routines. The tpacallQ function also 
This is used later as a parameter by the client AP when it calls 
service response to a specific earlier request. 



service 



The 56 services are invoked 

is established and the 
tpseidi) and tprecvQ for 
Conversations take place in 
XATMI does not allow the 
the conversation. The 
tpre um{) 



by ; 



a tpconnect{) request from the client AP. Once the connection 

invoked, the client and service can exchange data using 
an indefinite period of time in a conversational manner. 
half duplex mode; that is, only one AP can send data at a time, 
receiver AP to send data until the sender AP yields its control of 
con^iection request is completed when the service routine calls 
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For de tails of this interface, see 



3.7.3 The C PI C, Version 2 Interface 



For dii itributed applications usip; 
throuj ;h an application-definec 
(CPI-C ), Version 2 interface^ in 



The 



conversational model of 
industry today, and a wide 
historically thought of in terrhs 
A conversation 
to communicate 
Version 2 provides the 



convenation 



the 
CPI-C 



pi ograms 



The 
Sysb 
to 
6.2 



cn 



Pro 'ram 



(LI J 



A prirjiary benefit of this desig; 
to the underlying network 
environments. The interface's 
system connectivity and eases 
suppo "ted environments. 



Note: 



5. This speciflcatic 
between an AP 



6. See the referena d 

7. See the refereno d 



the referenced XATMI Specification. 



g a conversational paradigm, where communication takes place 
exchange of messages, X/Open offers the CPI Communications 
iddition to the XATMI interface (described above). 



3rogram-to-program communication is commonly used in the 
variety of applications are based on this model. The model is 
of two applications speaking and listening, hence the term 
simply a logical connection between two programs that allows 
with each other. From an application's perspective, X/Open 
fiinction necessary to enable this communication. 



C conversational mod.el is implemented in two major communication protocols: Open 
Interconnection Distrijuted Transaction Processing (OSITP)^ and Advanced Program- 
Communications (\PPC). The APPC model is also referred to as logical unit type 
6.2). X/ Open CPI-C, Ve rsion 2 provides access to both communication protocols. 



1 is that CPI-C, Version 2 defines a single programming interface 
protocols across many different programming languages and 
"ich set of programming services shields the AP from details of 
Ihe integration and porting of the application programs across the 



The X/Open CPI-C, 
produced by the 
differences: 



> Version 2 Specification derives from the CPI-C 2.0 specification^ 
CPII-C Implementors' Workshop, but with the following major 



X/Open CPI-C, 
languages. 



/ersion 2 only supports the C and COBOL programming 



— X/Open CPI-C, Ve -sion 2 does not support the concept of a distributed directory. 

Relat; onships between the Communication Paradigms 

Where different applications u; e the same CRM communication paradigm, X/Open facilitates the 
follow ing goals of paradigm co: isistency: 

from 



OSI TP standards. 

CIW CPI-C Specification. 



Ap plications are portable 

Different TM domains can i 
the OSI-TP protocol. 

If t le XA+ interface is used, 
is optional). 

Relaticjnships between different CRM communication paradigms are not determined by the model 



one TM domain to another, 
nteroperate within the same communication paradigm by using 

different CRM implementations are interchangeable (this feature 



n supersedes the X/Open Pe^r-to-Peer Snapshot, published in 1992, as one of the three X/Open interfaces 
ind a CRM. 
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3.8 



High 

X/Op 



n has adopted a hig. 
Definition Language (STDL). 
highei , language-syntax, level 
which take the form of embedded 
X/Op;n CRMs in order to provide 
STDL Preliminary Specification 



An Aff writer can use the 
ns that involves 
)f the TX interface to 
STIDL syntax in place of the 



operaljioi 
place 
use 



level TP Language 



High-level TP Language 



level TP language (HTL) called the Structured Transaction 
The purpose of the XHTL is to allow an AP to be written at a 
than the relevant X/Open APIs (namely the TX and CRM APIs) 
services. The XHTL is intended to be mappable to all of the 
CRM- and communication-paradigm independence. The 
is mapped only to the TxRPC CRM. 

XHTfL instead of the relevant X/Open APIs to specify a sequence of 
;s such as databases. The AP writer can use STDL syntax in 
coordinate global transaction management. An AP writer can also 
TxRPC interface for AP-to-AP communications. 



STDL mplements transactiona operations within higher-level syntax such as C or COBOL. AP 
writer; can choose to use STDL when they want to work at the language-syntax level, which 
provic es the benefit of syntax checking, potentially resulting in fewer runtime errors. Using 
STDL, the AP writer creates sejjarate STDL procedures that contain the transactional operations 
and tl at call C, COBOL or possibly other language procedures for other operations. STDL 
procecure calls are transactior al when the called procedures access RMs, and are optionally 
transa ;tional when calling remote procedures that access RMs. 

STDL supports both non-transattional and transactional modes (chained or unchained). 



See ths referenced STDL Specification 
relatioiship to the syntax of 
definit on of RM access and 



for further information about STDL syntax and its 
Dther languages such as SQL, C and COBOL, as well as the 
maj aping to the TxRPC protocol. 
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/appendix A 



equently Asked Questions 



How do existing products' stri ctures compare with the model's structure? 

See th ; questions below. 

What Jlements in the model le ad to a traiisactlon processing monitor? 

A Transaction Processing Monitor may often include both a TM component and a CRM 
component. It may also provide additional features outside the X/Open DTP Model such as 
task s( heduling and access to security subsystems. 

How 4oes the model handle npn-global transactions? 

not insist that an AP performs all work within the scope of a 



X''Ope 



en DTP Model does 
transaction. Work performed 
In non-global transaction 
coordinated by the TM. RIA 
commands, such as SQL 
performed is transactional and 
more IftMs are involved, there is 



The 
global 
transaction 
not 

interfalce 



An Al 

TM Di imain on page 5 for a deteition). The two approaches for such a combination are: 



Th( 

Thf 
the 



AP switches between non-global and global transactions, but never runs both types at 
same time. 



When 
it trans 
request , 



may choose to run non 



AP runs non-global and 



when no global transaction is defined is termed a non-global 
processing, one or more RMs are used by the AP, but are 
-specific work may be committed using the appropriate native 
COMMIT. As far as individual RMs are concerned, the work 
the ACID transaction properties are obeyed; but when two or 
no coordinated commitment between them. 



global and global transactions within the same TM Domain (see 



global transactions in parallel. 



In eithir case, the coordination 
applic^ tion design. Most 
transac tions 



Aft 



the global and non-global transactions is an additional issue of 
applications should not need to mix non-global and global 



What sire RM-internal transactibns? 

Many 1 IM products structure tl eir own work into transactions. An RM-internal transaction is a 
recovei able unit of work ownec by a single RM. In the X/Open DTP Model, a global transaction 
consist ; of one or more RM-internal transactions. The TM coordinates the start and completion 
of the I M-internal transactions of each participating RM. 

What elements in the model le6|d to a distributed database? 

In a d 



stributed database, the 
transaction it has internally distributed 
receives the transaction 
parently prepares any 



database RM manages the coordination of that part of the 
Therefore, in the model it is a single RM component, 
instructions from the TM — for example, a request to prepare — 
Subordinates before responding positively to the TM's prepare 
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Frequently Asked Questions 



Where 



A dist ibuted file system can 

That is , changes made to such 
the tra isaction. Such a file 
distrib jted file system to be 
interfape, in which case it woulct 



Can I i|ise the model for distributed systems management? 

be used as a transactional framework for distributed systems 
mplements CMIP or SNMP, for example, could, in conjunction with 
transE ctional systems management with atomicity across the various 
management CRM could do the transaction management entirely 
se rvices of existing RMs to provide ACID storage properties. 



agement. 



The X 
mam 

an X/ (ppe: 
objects 
on its 



'Open DTP Model can 
A CRM that ii 
n TM, provide 
and sites. The systems 
dwn, or it could use the 



Must c ommit occur in the same 



XA 



The 
contro: 



A client 
questic 
procesi 
just an 

A clien ; 
the 



I SCO je 



do distributed file syste ms fit? 



access data at multiple sites, but in general it is not transactional, 
file system are not coordinated atomically with other actions in 
system is outside the model. However, it is certainly possible for a 
implemented with transactional semantics and to support the XA 
beanRM. 



specification specifically 
from that which operated 
auxiliaby processes to optimise 



process that operated on the resources? 

allows the TM to commit a transaction in a different thread of 
on the particular resource. In addition, the TM itself may have 
Ihe commit process, and so may the RM. 



How d oes a client with just an AP and communication fit into the model? 



Each instance of the X/Open DTP 
A client, operating without a Tl^ 
but sue h a client is not part of any 
to thent are not coordinated by ijhe 



How daes a database client-ser/er architecture fit into the model? 



server database that 
n elaborates, the process 
, for example, may be thp 
internal part of the RM 



su pports 



X/Opei DTP Model components 

process mapping. There are seA' 
multiple processes, or that multi pL 



Peribrmance 

A component may have 
app ication logic; for exampL 

Inte mal distribution schemes 



For example, an RM may b^ a database with a client-server process model. Such an RM 
woi ld be expected to prwide the correct distributed semantics for its non-visible 
sub( )rdinates. 



Model must include a TM to provide transaction semantics. 

may send requests into a system that implements the model, 
global transaction. If such a client has local resources, updates 
system. 



the XA interface is an RM within the model. As the next 
structure is not identical to the model components. The client 
AP plus libraries from the RM and TM, with the server process 



-server database that dops not support the XA interface for transaction control is outside 
of the model. 



What ii ; the relationship betwet n model components and processes? 



(APs, TMs, RMs and CRMs) in no way imply a particular 

eral reasons why a single component may be instantiated with 
e components may be collapsed into a single process; 



separate processes to handle tasks somewhat asynchronous to the 
:, system management and logging. 
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Frequentiy Asked Questions 



Prs cticality of linking 

model component called the AP needs to communicate with the TM and each RM, and, 
iuch, must have within its process at least some library entry points that give it access to 

As described above, the TM and RM functions may result in 



Tht 

as 
the 
act 



ons being taken by a different process, but the AP needs at least a call-level linkage to 



An 
figure 



them, 
ex imple 



There 

model 
(securijty 

The X 
sites. 
X/Opdn 
included 
that is 
with 
the 

X/Ope 



TM and RM functions. 



of how the mode|l 
with ellipses indicating 



might be projected onto processes is shown in the following 
processes and rectangles indicating model components. 



RM \ 


RM 
Library 


/'rm" 

( Server 
\Process, 





Figure 



Is an }i/Open TM a transaction 
An X/Qpe 



n TM is a transaction 
transaittion. A transaction 

additic nal services such as 
X/Op( n TM should be thought 



Native 
API, 



TX 



TM / 


TM 


Library 




/^tmX 




( Commit j 


( Log J 


NProcess/ 


\JProcess/ 





A-1 Projection of Model onto Processes 



monitor? 



manager, and as such coordinates the atomic completion of a 
mbnitor (or transaction processing monitor) typically supplies 

dist ributed communication, task scheduling and other facilities. An 
of as a small, though important, subset of a transaction monitor. 



How c an I integrate existing products and services with products based on the X/Open DTP 
Model? 



existm: 



are two groups of 
(TMs, RMs and CRMs) 
subsystems, for examp L 



X/Op 
XTP 



ig products to consider: the system-level components of the 
and the products that provide services to those components 

le). 



Open DTP Model conce ntrates on transaction atomicity over distributed products and 
' 'he model does not preclude the incorporation of existing products. In fact, because the 
DTP Model allows fo: native APIs to the RMs, products with existing APIs can be 
. A product being incorporated as an RM or TM must have a two-phase commit ability 
compatible with the X/Open DTP Model. Also, for an existing product to interoperate 
en components, it must provide gateway software between the existing system and 
system. If these requirements are met, then the existing product can participate in 



n transactions. 
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Frequently Asked Questions 



There kre also existing product^ 
or user interface capability. 
transa;tion atomicity, but thej' 
applic ition environment. 

Finallj , it is possible to map bath 



it is possible to map 
additi(|)nal portability in existinj 



In terrjis of system component 
can i: 



that supply complementary functions such as security checking 

"^hese can also be incorporated. They do not directly support 
provide additional features to make a more comprehensive 



the X/Open HTL and APIs to existing products to provide 
product environments. 



How ap products implementii^ the model interoperate? 

integration, products that implement the XA or XA+ interfaces 
nieroperate. In terms of rjetwork interoperability, two products that implement the same 
commi mication paradigm can interoperate, but two with different communication paradigms 
cannot. For example, some requests generated by the CPI-C paradigm have no equivalent 
meanii ig in TxRPC. 



Can I Switch easily from one vendor using the model to another? 

mpdel allows for different 
RMs that provide the 
to move from an RD 3MS 
CRM. However, it is the 
ing the same RM or CRSs/ '. 



The 
between 

necess. iry 

xatm: 

supply 



Why aj-e there three communication APIs? 
The 



d veri 



th-ee communication APIs 
require ments and technology 
control afforded by the CPI-C p^adigi 
systems may. 



Canth 

Yes; fo 
precise 



example, the combination 
behaviour of such a combination 



native interfaces to RMs, and in general you can only switch 
same interface. For example, program recoding would be 
RM to an ISAM RM, or to move from a TxRPC CRM to an 
intent of X/Open that programs are portable between vendors 
API. 



currently supported were developed in response to both user 
gence. For example, many users may not require the precise 
m, but applications needing to interact directiy with legacy 



HTL and CRM APIs be combined in the same AP? 



of STDL and CPI-C in a single AP is possible, although the 
is not defined. 
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